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Migration from VAX to Alpha AXP 


1.0 SCOPE 

The Jet Propulsion Laboratory’s (JPL’s) experience migrating existing VAX applications 
to Digital Equipment Corporation’s (Digital) new Alpha AXP processor is covered in this 
document. The rapid development approach used during the 1 0-month period required to 
migrate the All Source Analysis System (ASAS), the 1.5 million lines of FORTRAN, C, and 
Ada code, are also covered. ASAS, an automated tactical intelligence system, was developed by 
the Jet Propulsion Laboratory for the U.S. Army. Other benefits achieved as a result of the 
significant performance improvements provided by the Alpha AXP platform are also described. 


2.0 INTRODUCTION 

2 . 1 Alpha AXP Processor Overview 

The Alpha AXP is the newest family of high-speed computers developed by Digital 
Equipment Corporation. The family includes several sizes of computers, from desktops to larger 
processors, all using the new Alpha AXP chip running at speeds of up to 200 MHz. The Alpha 
AXP utilizes a Reduced Instruction Set Computer (RISC) load-store architecture. All data is 
moved between registers and memory without computation, and all computation is done between 
values in registers. The Alpha AXP was designed to encourage multiple instruction issue 
implementations sustaining up to 10 new instructions per clock cycle. Current production Alpha 
AXP processors can execute two instructions per clock cycle, and Digital plans to release an Alpha 
AXP which processes four instructions per clock cycle by the end of 1994. 

The Alpha AXP architecture uses a linear 64-bit virtual address space. Registers, addresses, 
integers, floating-point numbers, and character strings, are all processed as full 64-bit quantities. 
The Alpha AXP can currently address 256 MB of physical RAM and up to 1 GB in future system 
releases. To run OpenVMS AXP, OSF/1 (UNIX), and Windows NT operating systems, the 
Privileged Architecture Library code (PAL code) provides memory management, exception 
handling, and other unique features to each operating system. By having different sets of PAL code 
for different operating systems, the architecture itself is not biased toward a particular computing 
style. The Alpha AXP architecture was designed with the following goals: 

• High performance. 

• Longevity. 

• To run OpenVMS and OSF/1 (DEC’s UNIX). 

• Easy migration from the VAX customer base. 

Currently, the Alpha AXP 3000 Model 500X, one of the mid-range Alpha AXP processors, 
outperforms all other processors in its class. The performance of Alpha AXP 3000 MODEL 500X 
against the SGI Challenge L, SPARCserverlOOO, and IBM RS/6000 is described in Table 2-1. 
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Table 2-1 . Comparison of SPEC92 results, single 
chip processors 


Model/Chip/Operating System 

SPECfp92 

SPECint92 

Digital AXP500X 

200 MHz DEChip 20164 
OSF/1 

159.6 

106.9 

SGI Challenge L 

150 MHz MIPS 4400 
IRIX 5.0 

96.5 

94.5 

SPARCserver 1000 
50 MHz SuperSPARC+ 
Solaris 2.2 

78.3 

66.5 

IBM RS/6000 
42 MHz RIOS-1 
AIX 

65.4 

32.9 


The longevity of the Alpha AXP processor remains to be seen, but the Alpha chip architecture was 
designed to support the product for the next 1 5 years. This is evident in the 64-bit address scheme 
and pipelining capabilities. 

The Alpha AXP processor currently supports three operating systems: (1) Open VMS, a 
new version of VMS containing POSIX compliant constructs; (2) OSF/1, Digital’s version of 
UNIX, and (3) WindowsNT. 

The PAL code is a set of routines that is necessary, but impractical, to implement as a 
single RISC instruction. Many of the Alpha AXP PAL code routines perform functions similar 
to complex VAX instructions, which on a VAX CPU are implemented in microcode. 

There are significant differences between the VAX and Apha AXP architectures. The. 
major differences are listed in Table 2-2. Clearly, Digital has been successful in achieving its goals. 


2.2 Rapid Development Methodology 

One of the integral components of any well-defined task is a set of guidelines that defines 
how a task will be accomplished. One of the key components of the AS AS Project’s approach to 
its Apha Migration activity was to use Rapid Development Methodology (RDM). This 
methodology facilitated our success through the following conditions: 

• Shortened development cycle. 

• Well-defined, short-term deliveries. 

• Team development concept. 

• Limited documentation. 

• Functional prototype for user evaluation. 
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Table 2-2. Comparison of Alpha AXP and VAX architectures 


Alpha AXP 

VAX 

64-bit addresses 

32-bit addresses 

64-bit processing 

32-bit processing 

Multiple Operating systems: 

One operating system: 

OpenVMS, OSF/1 , WindowsNT 

OpenVMS 

Instructions 

Instructions 

- Simple 

- Some Complex 

- All same length (32 bits) 

- Variable length 

Load/store memory access 

Permits combining operations and memory access in 
single instruction 

Severe penalty for unaligned data 

Moderate penalty for unaligned data 

Many registers 

Relatively few registers 

Out-of-order instruction completion 

Instructions completed in order issued 

Deep pipelines and branch prediction 

Limited use of pipelines 

Large page size (which varies from 8 KB to 64 KB, 
depending upon hardware) 

Smaller page size (512 bytes) 


This approach consisted of building a technical team with expertise in all the necessary disciplines 
to develop, build, and test software systems. The team was given a well-defined goal and the 
authority to accomplish that goal in the most efficient manner. If an existing process or procedure 
was not effective, the team could modify that procedure to accomplish its task. 

Typical software development activities following DOD-2167A involve a detailed review 
process and require a number of documents pertaining to software requirements, design, and 
implementation. With RDM, only a subset of the required DOD-2167A documentation is 
identified and written during prototype development. The specific subset of documentation 
selected for development is limited to those documents or portions of documents, that are necessary 
to guide the RDM activity. Upon completion of an RDM delivery, additional documentation could 
be developed, depending upon user requirements. 

This methodology typically saves money when compared to a full DOD-2167A 
implementation and quickly provides the customer (end user) with a working product for evaluation 
and demonstration. The end user can work with the product, evaluate it, and determine if it fulfills 
their needs. As a result of their early evaluation, the customer can request a series of system 
modifications and improvements to enhance system acceptance. These modifications can be 
incorporated into the next release. 
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2.3 Hardware Implementation 

For AS AS, incorporation of an Alpha AXP processor into an existing VAX system was 
necessary because of the ASAS Project’s dependency on the existing VAX configuration and the 
peripheral devices attached to it. One of the key objectives of the hardware migration was to 
provide state of the art performance and functionality, while maximizing reuse of existing 
hardware assets where applicable, and reducing the overall size and cost of the upgrade. Several 
ASAS systems were already fielded, being used by U.S. Army military intelligence units 
worldwide. The U.S. Army wanted to improve system performance at minimal cost. The Alpha 
AXP platform offered the first opportunity for such an upgrade. 

To begin the hardware migration, an evaluation of the existing configuration was 
performed. With formalized systems such as ASAS, the functional configuration information was 
available in the form of system description documentation. Key items considered in this evaluation 
were: 


• CPU. 

• Memory. 

• Bus I/O speed and formats. 

• Disk I/O format and disk capacity. 

• Communication device/network options. 

• Graphics controllers. 

• Monitors. 

• Printers. 

• I/O devices (keyboard and mouse). 

Aside from the functional issues, certain physical requirements must also be addressed. They 
include issues such as packaging, human factors, environmental, power consumption, and data 
connectivity. 

Once these issues were evaluated, a preliminary system was configured to begin software 
migration and further refine the workstation’s final physical configuration. For ASAS, the 
replacement Alpha AXP was directly integrated into the existing TEMPEST workstation housing, 
replacing the original VAX computer. The workstation was used to benchmark performance, test 
new and replacement functions, host existing hardware and software, and evaluate physical 
requirements issues. 


2.4 Software Migration 

Migration of software from VAX to the Alpha AXP was accomplished via one of two 
methods, native or vesting, depending on the status and availability of the new compilers for the 
Alpha AXP. The desired method is to compile and link the software using the new native 
compilers developed for the Alpha AXP processor. Performance increases from Alpha are not just 
the result of the faster processor. The compilers have been significantly rewritten to incorporate the 
pipelining and dual instruction capabilities of the Alpha AXP chip’s RISC implementation. 


4 




Migration from VAX to Alpha AXP 


Therefore, to obtain maximum performance benefits, native compiling is desirable. However, there 
are situations where native compilation is not possible, such as when a compiler is not available or 
when commercial products have not been upgraded to run on the Alpha AXP environment. Digital 
expected that this situation would occur during the early stages of release of the Alpha AXP, and 
they provided a capability to run existing VAX binary images directly on the Alpha AXP. Digital 
developed the DECmigrate utility to convert VAX instructions to Alpha AXP-understood 
instructions, bypassing the compile and link steps altogether. The process is termed vesting. There 
is a processing penalty incurred when running vested code. Performance of vested executables on 
Alpha AXP processors will be an improvement over performance on a VAX, but will fall short of 
the performance gains possible when built native. However, it may be the only viable alternative to 
quickly migrate software to the Alpha AXP. 

The number of VAX code modifications necessary before a successful compile and link can 
be achieved varies for each Alpha programming language. For example, on ASAS, two major 
subsystems were written in ADA. The Alpha AXP ADA compiler is virtually identical to the VAX 
ADA compiler, and the migration of these two subsystems (about 80,000 lines) was accomplished 
in less than two weeks. On the other hand, the PASCAL compilers were significantly different. 
Software written in Pascal required substantial code changes (10%— 15%) to conform to new 
standards and to compile successfully. The bulk of ASAS code was written in FORTRAN and C, 
and typically required only minimal changes to compile. 

To take full advantage of the Alpha AXP’s speed and architecture, all data segments 
(variables) must be word-aligned — that is, each variable should be mapped to start at the beginning 
of a 128-bit quadword. Since the VAX architecture entailed the use of 32-bit words, and there was 
no real performance impact for mapping data to sub-word boundaries, a complete remapping of 
data to the Alpha AXP’s quadword boundaries would be necessary to obtain optimum system 
performance. However, for ASAS, such an activity would entail complete remapping of all data 
structures system wide. The cost of that activity was prohibitive, so we chose to compile our 
modules with the NOALIGN option, not reformatting our global areas. (A speed reduction penalty 
is paid for using this option, but overall performance is still much faster when compared to the 
VAX versions of ASAS software. See section 4.3.2. for additional details.) 

The software migration schedule was further reduced, thanks to the performance of the 
Alpha AXP, in compiling, linking, and debugging activities. The Alpha AXP’s speed in building 
software significantly increased the productivity of the software development team. For example, 
to compile and link a large subsystem consisting of more than 210,000 lines of FORTRAN code 
expended twelve (12) hours of clock time on a VAX 3800. With the Alpha AXP, the same compile 
and link takes only 5 1/2 hours. The same was true for all 23 subsystems in ASAS. The build and 
test cycle was shortened significantly, thereby increasing the productivity of software developers. 

As subsystems were migrated, tested, and benchmarked on the Alpha AXP, the benefits of 
migration were proven quickly and dramatically. Processing times were dramatically reduced 
when compared to times required to perform the same operations on the VAX. In some cases 
graphics operations that would require over 90 seconds to complete on the VAX, would complete 


5 




Migration from VAX to Alpha AXP 


in less than 5 seconds with the Alpha AXP. We typically observed a 20 to 30 times improvement 
in performance. 


3.0 MIGRATION GOALS 

3 . 1 System Engineering Goals 

Effective system engineering during development of the Alpha AXP version of AS AS 
added value to the migration effort. While ASAS met most functional specifications, system 
performance of earlier VAX 3800-based systems has always been considered to be poor. Software 
modifications could only offer a partial solution, as significant improvements could only be 
obtained with new hardware. Several potential improvements were identified and prioritized at the 
start of the migration effort to determine whether hardware and/or software solutions could be used 
to solve the performance bottleneck. In addition, many system level issues were identified. The 
following goals were identified: 

• Develop an integrated product (hardware and software) providing functionality 
identical to the current system. 

• M inimi ze changes to the user interface. 

• Define potential new system configurations. 

• Prioritize system anomalies. 

• Identify third party software alternatives to existing products that provide additional 
capabilities (upgrades). 

• Identify hardware alternatives to existing products that provide new or additional 
capability. 

• Identify key operational bottlenecks. 

For the ASAS Alpha migration the system engineering process required a knowledge of 
how ASAS is operationally used. ASAS is one of many tactical systems used by the Army. 
Interoperability of ASAS with other tactical military systems was a critical issue and had to be 
assured. In fact, the migration activity provided an opportunity to upgrade or add interoperability 
capabilities which did not exist. 

3.2 Hardware Goals 

The goals of the Alpha migration effort were quite straightforward from a hardware 
perspective. The Alpha system had to meet all system specifications developed for the original 
VAX processor. The specific set of hardware goals is listed below: 

• Minimiz e effort for retrofit of existing systems in the field. 
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• Maximize reuse of existing workstation hardware components (excluding the Alpha 
AXP CPU itself). 

• Meet or exceed the current system’s interoperability performance requirements with 
other systems. 

• Reduce overall system footprint. 

• Meet or exceed all existing system specifications for functional performance, 
including these factors: 

Environmental conditions 
Operating temperatures 
Reliability 
Maintainability 
TEMPEST 


3.3 Software Goals 

The goals of the software migration effort were to retain complete system functionality 
while improving overall system performance. More specifically the goals were to: 

• Maximize use of native code versus vested code. 

• Maintain an identical look and feel for the user. 

• Retain the existing software architecture, unless a system engineering assessment or 
operating system constraint dictated that a modification was necessary. 

• Utilize the identical commercial software baseline used in the VAX processor. 

• Maximize use of production software versus beta-test versions. 


3.4 Cost and Schedule Goals 

Cost and Schedule considerations were also quite simple; provide a completely working 
product within a very short time period and within a relatively small budget. Specific goals 
were: 


• Minimize system development costs for both hardware and software to establish 
proof-of-concept through RDM. 

• Shorten delivery schedules to demonstrate capabilities and benefits of migration by 
rapid prototyping. 

• Define high risk items early, preferably during the planning stage, and develop 
contingency plans. 

• Produce the first prototype within three months. 

• Produce a completely operational system within nine months. 
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4.0 MIGRATION STRATEGY 

4. 1 Rapid Prototype Approach 

JPL’s Rapid Development Methodology is an approach to system development (software 
and hardware) that provides working systems early and continues to provide a working product 
throughout the life of system development. RDM provides working products faster than can be 
achieved through application of the typical system development cycle. The use of RDM for the 
migration of ASAS was critical to the success of this venture. It allowed for quick turnaround of 
information. System users were provided with prototypes during the early stages of development. 
Their comments were easily accommodated and were reflected in the final system released to the 
field. 


The ASAS migration consisted of a four-phase effort. The first phase of that effort, 
prototyping, covered a 90-day evaluation period when the proof-of-concept was demonstrated. 

Vital planning information for a complete migration was obtained. The second phase, complete 
system migration, required the most effort. Both the hardware and software systems were 
completely upgraded for operation with the Alpha AXP platform. The third phase of the migration 
activity consisted of detailed system testing. Both the hardware and software systems were 
thoroughly tested. The fourth and final phase of the activity consisted of a complete retrofit of 
several existing systems. Both hardware and software were upgraded for two ASAS systems, 
currently in use by the U.S. Army in the field. 

The first 90 days of the effort were earmarked to be an evaluation period for identifying 
issues and allowing for a detailed analysis of existing applications. The key activity during this 
phase of the migration involved determining the feasibility and relative ease of a complete software 
migration to the new Alpha AXP processor. To meet that end, critical components of ASAS 
software were evaluated. The DECmigrate utility provided the team with flexibility to quickly vest 
those portions of the system required for the applications to run. Through a combination of vesting 
and native development, critical components of the system were migrated for the purposes of 
demonstration and evaluation. Additionally, the specifications for a workstation outfitted with an 
Alpha AXP was completed. By the completion of this phase, it was believed that a complete 
migration to the Alpha AXP was possible, and detailed plans for system migration were 
formulated. 

During this phase of the activity, the evaluation team was quite small, typically consisting 
of only four engineers. Their goal was to demonstrate the proof-of-concept and to identify potential 
technical hurdles to a complete system migration. The team selected specific time-critical 
processes to be migrated in order to benchmark Alpha AXP performance. The initial 90-day period 
provided sufficient data to develop a comprehensive task plan for the complete migration effort for 
both hardware and software. The comprehensive task plan for the complete migration was used in 
subsequent phases of the effort to allocate personnel and hardware to the task. The allocation of 
system’s versus application’s programmers was approximately a 30/70 split. The addition of test 
and configuration management to the team provided the full compliment of resources to build, test, 
and support the migration. 
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Hardware and software staff worked together to identify, resolve, and isolate interface 
issues between the hardware and software. In the ASAS migration effort, developers on the team 
had a knowledge base from completing the design and development on the VAX. Although this 
experience was valuable, ultimately the most valuable knowledge was that of the architectural 
differences between the two platforms and the technical information gained from the 90-day 
evaluation. 

The migration schedule also benefited from the Alpha AXP's increase in performance 
through a dramatically reduced build cycle. Prior to introduction of the Alpha AXP, a complete 
compile and link of ASAS software required about 2 weeks (10- to 8-hour days). The Alpha AXP 
reduced a complete build cycle to just 2 1/2 days. The increased turnaround enabled the migration 
team to identify and correct reported problems at a much higher rate than on the VAX 3800s. 

4.1.1 Phase I-90-day Evaluation Period 

An early evaluation of both hardware and software was necessary to identify the 
corresponding components for the new Alpha AXP based system. A 90-day evaluation period was 
established to identify component level details of all hardware and software items necessary to 
build a prototype system. The goal of the prototype activity itself was twofold: (1) to prove that 
migration of the ASAS code was possible, and (2) to develop a strategy for migration of the entire 
VAX3800-based product to the Alpha AXP platform. 

The prototype effort began with evaluation of available documentation describing the VAX 
3800-based system. In most cases, documentation was available to describe the hardware and 
software components to a sufficient level of detail to allow work to proceed. In those cases where 
documentation was not available, the migration proceeded through detailed physical analysis of the 
existing system. For hardware, the approach was to dismantle an existing fielded system to identify 
components, revision levels, and connectors. For software, when documentation of commercial 
products that reside in the system were not available from vendors, the vendors provided direct 
support through phone and other forms of communication. 

After identification of the hardware and software items was completed, an Alpha 
configuration plan was devised and a task plan was developed to address specific technical issues 
related to that configuration. With a migration effort, some items (either hardware or software) 
transferred very easily to the Digital Alpha AXP environment. Some items required a unique 
technical plan to accomplish the migration of that specific item. For example, the ASAS VAX 
system used a communication interface board (e.g., DSV1 1) to provide a number of protocols to 
external communication devices. On the Alpha AXP, a new interface board had to be configured 
and the software supporting that device had to be developed to provide equivalent functionality. 

The integration of a new communications interface board warranted a detailed task plan within the 
migration activity. 

With the target Alpha configuration and a task plan defined, a schedule for the development 
of a prototype was developed, based upon the task relationships and dependencies. An integral part 
of this schedule was the procurement of hardware items and software packages for the Alpha AXP. 
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The establishment of a complete software configuration and development environment was 
also accomplished at this time. The necessary compilers, COTS packages, and support tools were 
obtained and installed on an Alpha AXP. Additionally, Digital’s software configuration 
management tools for the Alpha AXP Code Management System (CMS) and Module 
Management System (MMS) were installed. 

The availability of test tools and data that could be used for the integration and test activity 
was evaluated, as well. It was found that test procedures and data existing from the original 3800- 
based software development activity could be used for the integration and test activities of the 
Alpha AXP migration. Extra time was added to the task plan to cover areas where the existing test 
procedures were found to be inadequate. Once completed, the task plan included time for the 
development and modification of test scenarios and data to validate the accuracy and completeness 
of the migration. 

At the conclusion of the prototype phase of this activity, the Alpha Migration staff had a 
good handle on the following key items: 

• Prototype Alpha AXP hardware configuration. 

• Prototype software configuration. 

• Integrated task plan and schedule. 

• Software development environment. 

• Procurement plan for all required hardware and software items. 


4. 1 .2 Phase II - Implementation 

The implementation of the task plan required assignment of key personnel to all tasks 
according to the task plan description in the previous phase. In addition to having personnel 
experienced with code migration to the Alpha AXP (from the prototype effort), the AS AS Project 
also brought experienced personnel from previous AS AS code development activities to this phase 
of the effort. The hardware and software implementation activities were performed in parallel to 
support a common integration milestone. The details of the hardware integration were rather 
complex but were not directly coupled to the ASAS software. Consequently, the hardware 
implementation was performed independent of the software development activities. This action 
permitted testing of specific hardware (e.g., TEMPEST testing) requirements without impacting 
software development activities. 

Software migration was performed in a bottom-up fashion. The lowest level of the software 
baseline (i.e., OpenVMS Operating System) was installed first and then commercial third-party 
products were installed on top of OpenVMS. Those products included such items as a database 
management system and a forms manager. The ASAS Project’s experience has shown that 
matching third-party software packages to the current version of OpenVMS was critical to a 
successful migration. System failures often occurred when these third-party products and the 
operating system were out of synchronization. 
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Having established the operating system and support software packages necessary for 
running the application, the migration of the applications began. The software migration schedule 
was derived, usually, from the software design and the software hierarchy. The lowest level 
routines and subsystems were migrated first. The complexity of the migration was a function of: 

• Standards used during software development (how well the original programmers 
conformed to system specifications). 

• Languages used for implementation. 

• Whether the software was built native or vested. 

The complexity of the migration was a function of the standards used for initial development of the 
software. VAX software written in FORTRAN or C that compiles without errors, may not compile 
on the Alpha AXP. The compilers have been rewritten for the Alpha AXP to take advantage of the 
capabilities of the Alpha chip. The code optimization features of the Alpha AXP compilers are 
much more sophisticated than those on the VAX. Depending upon the language, the code 
modifications required varied. Based upon the ASAS Project's experience with approximately 1 .5 
mi l l ion lines, JPL developed ASAS code. The following estimates about the magnitude of 
software changes necessary to recompile are listed below: 

Language Approximate Impact 


ADA 

< 1 % 

FORTRAN 

<5% 

C 

< 10% 

PASCAL 

< 15% 


The complexity of the software migration was also a function of whether the application 
could be built completely native, or whether some of its components had to be vested. The ASAS 
Project's guidelines for migration required that Smartstar, a forms management package, be 
retained. Since Smartstar is a BASIC (language) program, and BASIC compilers were not 
available for the Alpha AXP, the only alternative was to vest the Smartstar software package. The 
interactive application code, however, was typically written in FORTRAN and was compiled native 
using the new Alpha AXP compilers. The final executable, however, being a concatenation of JPL- 
developed source code and Smartstar, contained both native code and vested Smartstar routines. 
Although there was a performance "hit" for linking both native and vested software together in the 
same executable, the performance was still dramatically better than the VAX. 


4. 1 .3 Phase III - Prototype Testing 

As subsystems of the application were migrated to the Alpha AXP, testing of the prototype 
began at the subsystem level. As part of the original software development activity, test procedures 
and data were developed to validate system requirements. Existing test procedures and data were 
used for testing and integration of the prototype. Code changes were necessary to address 
migration-specific issues, such as floating point format differences. In addition, problems existing 
in the software surfaced due to differences between the VAX and Alpha AXP architectures. A 
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number of instances occurred in the ASAS Project’s migration where a particular coding practice 
on the VAX would work, but that same approach on the Alpha AXP produced the wrong result. 

Differences between VAX and Alpha AXP required tuning of Open VMS system 
parameters to optimize performance. Typically, executable images on Alpha AXP are much larger 
due to the RISC instruction set. Because the size of executables is larger, memory becomes a 
critical resource in reducing page fault rates. The evaluation of system performance and tuning of 
the configuration provided valuable information into finalizing the Alpha AXP configuration. 

Operational testing of the prototype was a critical step in validation of the migration and 
demonstration of the performance improvements. In addition to the completion of another level of 
testing, evaluation of new system capabilities was performed. Upon completion of performance 
tuning and operational testing, new performance levels were demonstrated The ASAS Project’s 
mi gration to the Alpha AXP allowed a new system configuration with 6 Alpha AXP 500s rather 
than 1 0 VAX 3800s. Performance increases of 10 to 30 times were realized even with a reduced 
set of processors. The performance data collected from integration testing will support the 
definition of new (reduced) system configurations. 


4. 1 .4 Phase IV - Retrofit Existing Systems 

After the hardware and software prototypes were completed and validated, a detailed task 
plan for retrofitting existing 3800 configured systems was developed. Two 3800 systems 
previously fielded to the U.S. Army were identified as candidates for the initial upgrade. 
Components were ordered, and the Central Processing Unit (CPU) portions of the workstations 
were returned to JPL for retrofit. Once completed, the complete systems were tested at JPL and 
later at Fort Hood, Texas. After successful completion of this phase, the systems were returned to 
the Army for evaluation and operational use. 


4.2 Hardware Configuration Definition 

Using the hardware goals identified in Section 3.2, each functional area of the VAX 
workstation was evaluated and the trade-offs analyzed. Even though these goals dealt with the 
procurement of hardware items, software and system engineering issues had be considered as well. 
Through a well thought out combination of hardware and software upgrades, the proper hardware 
was selected. The ASAS Project’s experience with the migration of ASAS to the Alpha 
demonstrated that: 

1) Performance enhancement was not solely the function of the CPU speed, but rather a 
combination of CPU, RAM capacity, bus throughput, and disk I/O. By providing 
increases in some or all of these areas, significant performance gains were realized. 

2) Specific performance increases could be measured after portions of the target 
software were migrated to the Alpha. Consequently, system performance for a 
completely migrated system could be modeled after completion of the first prototype. 
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3) The rapid prototype approach provided shortened schedules and frequent deliveries 
that allowed us to address changing customer priorities and goals. 


4.2. 1 Alpha AXP Hardware Functional Requirements 

All hardware components of the ASAS workstation were evaluated during the initial 
prototyping activity. Based on analysis of prototypes results, recommendations were made in the 
following areas: 

• CPU. 

• Memory. 

• Disk I/O Format and Disk Storage Capacity. 

• Communication. 

• Network Connectivity. 

• Bus I/O Speed and Format. 


As each component of an existing configuration was evaluated, its Alpha AXP equivalent typically 
provided better performance in a smaller physical package with improved reliability. A comparison 
of VAX and Alpha AXP components is provided in Table 4-1 . The comparison between a VAX 
3800 and an Alpha AXP 500 provides insight into the significant differences in performance and 
throughput that can be realized. 


4.2.2 VAX versus Alpha AXP Trade-off 

As previously mentioned, the Alpha AXP offers significant performance boosts for 
ASAS applications formerly running on VAX 3800 processors. The power of the new Alpha 
AXP CPU and its memory are the key to this improvement. The capabilities of VAX 3800 and 
Alpha AXP are compared at a functional component level in the following paragraphs. In every 
case, the performance improvements were substantial. 


4.2.2. 1 Central Processing Unit Comparison 

The VAX 3800 CPU processor is a 32-bit processor which runs at 33 MHz and can address 
a maximum of 64 MB physical RAM. Architecturally, the VAX 3800 architecture is based on a 
Complex Instruction Set Computer (CISC) design. All aspects of the VAX 3800 have been 
improved upon with the introduction of the Alpha AXP. For example, the Digital 3000 model 
500X AXP, one of the line of Alpha AXP processors, offers significant improvements in 
processing capability. Its CPU speed, clocked at 200 MHz, operates under a 64-bit architecture (the 
source of many migration issues). The Alpha AXP is a RISC-based system that currently has the 
ability to address 256 MB of physical RAM. Future operating system releases are expected to 
support up to 1 GB of RAM. As an industry reference. Digital provides a SPECMARK89 
measurement of 1 1 8+ and a MIPS measurement of 1 5 1 . 
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Table 4-1. VAX versus Alpha AXP Component Comparison 


Functional Area 

Current System Configuration 

Proposed System Configuration 

Advantages and Tradeoffs 

CPU 

VAX 3800 
CISC 3.8 specmark 
33 MHz Bus design 
64 MB RAM max. 
32-bit architecture 

Alpha AXP 
RISC, 118+ specmark 
150 MHz Workstation 
1 GB RAM max. 

64-bit architecture 

RISC performance enhancement. 

Alpha AXP clock rate significantly higher. 
Faster CPU, Memory, and I/O. 

Increased memory capacity. 

Performance improvements. 

S/W migration. 

Chassis modification. 

MEMORY 

DR-300-32 
Q-Bus I/O 
64-MB max. 

64 MB SIMMS 
Alpha AXP resident 
256/1 GB max. 

Faster memory handling. 

Larger addressable memory. 
Memory trade-in Physical Layout. 

DISK I/O 

QD21 ESDI issues Q-Bus 
I/O 

MSCP only 

Two device limit 15 Mbit/s 

SCSI-il + SCEA Adapter 
SCSI-11 

Alpha AXP res. (SCSI-II) 
MSCP/TSCP (SCSI-II) 

Seven Devices (SCSI-II) 5 MB/s 
(SCSI-II) 

Standard device I/O saves space. 

SCSI-II handles various device types. Multiple 
devices. Faster Data I/O adapter allows most SCSI, 
virtually limitless device interface. Can support RM 
option with same HA Adapter. Allows seven deep. 
Forty-nine available SCSI addresses. Unable to use 
Q-Bus PCB in Alpha AXP. Cannot use ESDI Disks. 

Storage 

Maxtor 760 

760 MB 5.25" form factor 
18 Ms AVG Seek Time 
15 Mbits/s 

Seagate/Hitachi 1.2-1 ,4GB 
3.5” form factor 
9 ms AVG. Seek Time 
5 MB/s 

Larger storage 
Smaller 
Faster Access 
High I/O rates 

COMM Serial 
I/O 

CM-DHV1 1 
8 channel/Async 

38.4Kmax. I/O 
Q-Bus 

Magma 8+2 
8 channel Async I/O 
2 parallel ports 
38.4K max. I/O 
Turbo channel 

Duplicated functionality. Two parallel ports for 
flexibility. Unable to use Q-Bus PCB in Alpha AXP. 

Network 

EXOS 203 
Q-Bus 

Ethernet 802.3 
Dual rail 

None Required 
Alpha AXP resident 
Ethernet 802.3 
Thinwire 

Use existing channel. TCP/IP supported. 
Unable to use Q-Bus PCB in Alpha AXP. 
Extra net board required. 

SCSI 

CQD-220 
SCSI for Q-Bus 
MSCP/TSCP 
4.8 MB/s Transfer 

SCSI-II + Adapter 
See above 

Saves Turbo channel. 

Unable to use Q-Bus PCB Alpha AXP. 

BUS I/O 

Q22 

32-bit design 
72 (some lines red) 
3.3 MB/s avg. 

5.0 MB/s burst 
All functions need 2 
available slots 

Turbo Channel 
64-bit design 
96 lines 
50 MB/s avg. 
100/MB/s burst 
4 functions on board 

Requires new controller. 

Unable to use Q-Bus PCB in faster bus. More 
functions resident on system 


4.2.2.2 Memory Comparison 

Advances in RAM capacity offered many options to consider in this area. Current VAX 
3800 configurations consist of a single 32 MB PCB and can be configured to support a maximum 
of 64 MB. 

Memory configuration of the Alpha AXP is most similar to the memory design of common 
personal computers or workstations, using Single In-line Memory Module (SIMM) insert boards. 
Because SIMM sets are smaller (5.65" X 1.0"), higher in density, and snap directly into the mother 
board, the memory design has smaller space requirements and faster cycle and access times. Other 
notable points include expansion and performance. Currently, the OpenVMS and OSF/1 operating 
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systems can address 256 MB of RAM. Future versions will expand RAM capacity to 1 GB. 
Although the 16 Mbit chips are not ready for release, the concept of a workstation with 1 GB RAM 
will open a wide range of possibilities. Creation of memory resident tables and processes that need 
not be accessed over a bus or through disk I/O are closer to reality. 

4.2.2. 3 Disk I/O Format and Disk Storage Capacity Comparison 

Disk I/O and storage capacity were two areas in which performance increases were realized 
during the upgrade to the Alpha AXP. A typical ASAS VAX 3800 configuration uses Maxtor XT- 
8760E ESDI hard disk drives. Disk I/O is controlled by the Emulex QD21 in the current design. 
This ESDI controller provides emulation of Digital's Mass Storage Control Protocol (MSCP) small 
device interface to the hard disk. The QD21 has limited connection capacity and can only handle 
two MSCP peripherals. 

The disk configuration for an Alpha AXP-based system used the Small Computer Systems 
Interface, version II, (SCSI-II). Special external controller boards are not required since the 
controller is resident on the Alpha AXP mother board itself. The SCSI-II control interface is 
capable of handling two independent SCSI bus configurations. Each bus can support seven MSCP 
and TSCP devices. Consequently, the Alpha AXP mother board is capable of supporting access to 
fourteen SCSI-II compatible peripherals. 

There were many commercially available options for the fixed disk capability at the time 
the retrofit was being designed. The minimum requirements for the media were (1) SCSI-II 
interface, (2) minimum storage capacity of 1.2 GB, (3) 3.5-inch form factor, (4) average access time 
no more than 9 to 10 milliseconds, and (5) a minimum data transfer rate of 10 MB/second. The 
first workstations were equipped with 1 .2 GB disks. Subsequent systems were equipped with 
1 .4GB disks which became readily available during the hardware system development phase. With 
the growth of higher density disk drives, future workstations may be equipped with 2.5 GB drives. 
With the combination of the aforementioned SCSI-II throughput speed and the increased 
performance of the new SCSI-II high density disks, the Alpha AXP-based work station measurably 
increased disk I/O. 

4.2.2.4 Communication 

The VAX computer has no built-in communications capability. Add-on communication 
boards are required in all cases. The Alpha AXP computer comes with communications port 
capability built into the mother board. Its features are identified below: 

Asynchronous Communication — The Alpha AXP system comes equipped with one 
asynchronous communication port, RS-423A. The Turbo channel option available from 
MAGMA, Inc. is the MAGMA 8+2. It will support eight asynchronous channels and two 
parallel ports which allow for the use of various output devices provided as printer 
subsystems. 
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Network Communication — The Alpha AXP has an Ethernet port resident on the 
motherboard. This port supports IEEE 802.3 standard Ethernet. 


4.2.2. 5 Bus I/O Speed and Format 

The VAX bus design routed all communications through the back plane Q-Bus. The Alpha 
AXP bus concept is significantly different. Because of the motherboard approach and the move 
away from the "one function equals one board" thinking, the proposed Alpha AXP has only a 
limited need for bus options. Memory, SCSI-II, Ethernet, graphics acceleration, and 
communication options have all been placed "on board," making system I/O between these 
processors faster. 

Alpha AXP-based machines currently have a design for I/O interfaces called Turbo 
Channels. The data rate of the Turbo Channel is 1 00 MB/s (burst) with a standard throughput of 
50+ MB/s which is a significant improvement over the Q-Bus which operates at a maximum burst 
of 3.3 MB/s. 


4.2.3 Physical Configuration 

The activity involved in introducing a Digital Alpha AXP processor into the current fielded 
hardware platform as a replacement for the existing 3800 VAX processor is described in this 
section. As part of the RDM philosophy, JPL’s approach was to use as few engineering designs 
and production steps as possible. Prototypes were developed, quickly tested and evaluated, and 
modified, as needed. Ultimately, a final design configuration was completed. Available 
technology, such as prepackaged rugged workstation processors and rack/chassis mountable 
devices, permitted rapid delivery by using a simple assembly process and minimum functional 
testing to produce a large quantity of reliable systems for retrofit in the field in a very short period 
of time. 


4.2.3. 1 Use of Commercial Hardware 

While the use of commercial off the shelf systems (COTS) is adequate for most business 
and scientific applications, the use of COTS products is of concern when implementing systems for 
military use. While AS AS must conform to strict requirements for TEMPEST and EMI shielding 
for all fielded systems, the customer allowed the use of COTS products during the prototype 
development. There are cost advantages to using commercial hardware in a fielded system. 
However, there are several issues that require immediate resolution. Security, environmental, and 
logistical concerns are the most critical. 

For example, when using COTS hardware in a DIA accredited system, all previous 
TEMPEST and EMI testing and approvals are considered invalid. In order to maintain system 
approval, special waivers to use COTS hardware for classified processing had to be secured for the 
interim. Also, using COTS equipment upon completion of the prototype negates certain 
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environmental tests performed on the current system. Special consideration and waivers may also 
be necessary during this phase as well. 

Using COTS hardware during the interim stage may have a certain impact on tr ainin g and 
maintenance. However, in this instance, the AS AS Project recommended no changes to training 
and maintenance material during this phase. 

The use of COTS hardware provided immediate performance gains in all areas. Even with 
the aforementioned concerns, the use of COTS in the field to realize these immediate performance 
gains and elicit feedback from the users may be an option. 

4.2. 3.2 Use of Existing Assets 

For this hardware upgrade, the sponsor’s specifications required the use of existing assets 
for the prototype system, when possible. Through evaluation of the existing system, all interface 
formats for peripheral devices (drives, monitors, etc.) were determined. As stated previously, one 
design goal was to use as many of the main components of the existing system as possible. By 
using existing components, cost savings could be realized in the areas of acquisition, training, and 
maintenance. 

There were several candidate devices in the ASAS system configuration that were 
considered for reuse including monitors, optical disk drives, keyboards, and mice. The costs and 
time associated with developing new, rugged components is motivation to use existing assets. 

There were several technical issues associated with this strategy, but the challenges were met by 
the engineering staff. For example; the rugged monitor in the ASAS workstation is a dual scan 
monitor with a maximum vertical scan rate of 54/kHz. The Digital HX Graphics Accelerator board 
provided with the standard Alpha AXP workstation will only drive monitors with a minimum scan 
rate of 66 kHz. This problem of incompatible scan rates was solved through direct communication 
with Digital. After proving the concept, JPL contracted with Digital to modify their graphics board 
to drive the existing monitors. 

4.2. 3. 3 Packaging Issues 

Packaging the Alpha AXP CPU into the existing workstation design was not easy. The 
standard size and form of the workstation had to be retained. Standard connectivity to all 
peripheral devices had to be considered as well. The major issues are listed below: 

1) Data Interface: Each physical connection on the VAX had to be duplicated for the 
Alpha AXP. This meant that interface cables for each connection had to be fabricated 
for each external interface. Sketch engineering based on existing interface designs 
reduced costs. JPL had experience in building interface cabling and with limited 
production of cable at reduced costs (as compared to full production cost). 

2) Power : Alpha AXP systems are specifically designed for the commercial office 
environment, reducing the requirements for power significantly when compared to 
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their VAX equivalents. Packaging these systems for fielded systems allowed 
alternate power supplies to be considered. The Alpha AXP design has incorporated 
the SCSI controller, Ethernet controller, and RAM onto the “mother board.” This has 
significantly reduced the power consumption for each workstation. 

3) Environmental: Environment all requirements fall into four basic categories; thermal, 
shock, vibration, and TEMPEST. The commercial Alpha met certain tolerances, 
however, it did not meet the existing military requirements. Design of the prototype 
had to account for the following issues to meet or exceed the current capabilities in 
the field including: 

• Airflow thermal exchange, operability under high temperatures. 

• Shock tolerance. 

• Vibration (operational and non-operational). 

• Radiated emissions. 

• Dust. 

• Noise. 

Accommodating these environmental requirements played a large role in the cost of 
replacing a fielded system. 

4. Logistics: Documentation, training, and maintenance were integral parts of the 
transition to the proposed system. During the migration phases, all existing 
equipment, drawings, manuals, and tools were evaluated to reflect the system 
upgrade. Reuse of existing manuals minimized the impact and the cost to the 
development of new training and maintenance materials, as well as the drawing 
packages. 


4.2.4 Alternate Configurations 

As a result of performance improvements from migrating to the Alpha AXP, the physical 
configuration of the AS AS enclave was reduced. With the VAX 3800-based configuration 
(Figure 4-1) four support processors were required in addition to the six workstation processors 
to perform compute-intensive activities. Still, processing backlogs of several hours were not 
uncommon during periods of high message traffic. 

The AS AS Alpha AXP enclave configuration (Figure 4-2) has enough processing power 
to eliminate the need for the four support processors. The background automatic processes, 
which were previously loaded on the four support processors, are now loaded directly on the 
workstation processors in tandem with all analyst operations. Still, no performance degradation 
has been identified, either to automatic or analyst operations. The Alpha AXP configuration did 
not experience any backlogs in processing data, even for periods of high message volume. 
Finally, the system could provide the commander with an integrated picture of the battlefield in 
real time. The performance improvements allowed the analyst to perform routine system 
operations faster and allowed them more time to perform their analysis functions. 
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4.3 Software Migration Approach 

4.3.1 Commercial Packages, Compilers, and Build Environments 

To begin the software migration, the development environment and build tools were 
installed on the Alpha AXP. For configuration management, the AS AS Project uses two 
Open VMS utilities that were previously supported under VMS: Configuration Management 
System (CMS) and Module Management System (MMS). CMS provides a repository for source 
code files and object libraries. It maintains a history of changes to source code files as they are 
edited by the programmer. MMS provides the description of dependencies between objects and 
executables. It provides developers with the capability to modify specific routines and relink only 
those executables that reference those routines. Since the Alpha AXP and VAX use the same Files- 
1 1 file system, transferring source code files was simple. 



1 PRINTER 


Figure 4-1. The ASAS 3800 Enclave. The enclave consists of six workstations and four 
support (background) processors. 
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Depending upon the languages and products used to build an application, some compilers were not 
available at the time of migration. While FORTRAN and C were available at the onset of the 
migration effort, Pascal and ADA were not available until later. Our experience with Digital has 
shown that they have been reliable in meeting their compiler release dates (Table 4-2). 


In addition to dealing with the late arrival of Digital S/W products, evaluation of the Third 
Party Commercial Software was completed. The products fell into the following categories: (1) 
database management system, (2) forms management, (3) graphics packages, (4) spreadsheets, 
and (5) network software. The evaluation of each product was focused on determining its current 
availability for use on the Alpha AXP with Open VMS. At the time of this migration effort, the 
Alpha AXP had been commercially available for only about one year, and many third-party 
vendors were completing their own migration to the Alpha AXP. In some cases, third-party 
packages were vested when native versions were not complete. A critical feature of DECmigrate is 
the capability to link both vested and native code in a single executable. This action facilitated the 
migration of the ASAS Software since the Smartstar forms management package had not been 
migrated by the vendor. 


FIELDED TO: 

IU CORPS, FT. HOOD, TX 
1 CAV, FT. HOOD, TX. 


EACH ALPHA AXP WORKSTATION ' CONSISTS OF: 

1 ALPHA AXP 500 COMPUTER 

2 MONITORS 

1 KEYBOARD, MOUSE 
1 REMOVABLE CARTRIDGE DISK 
4 1.4GB REMOVABLE DISKS 
SHARED PRINTER RESOURCES 


RUGGED AND COMMERCIAL CONFIGURATIONS 
AVAILABLE 



CCS/IO & 
COLOR 
PRINTER 


THIN- WIRE LAN 


> ALPHA AXP 500 COMPUTERS - PROVIDE WORKSTATION SUPPORT AS WELL AS BACKGROUND 
AUTOMATIC AND COMMUNICATIONS PROCESSING 


Figure 4-2. The ASAS Alpha AXP Enclave. The enclave consists of six workstations. The four 
support (background) processors associated with the 3800 enclave are no longer 
needed. 
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Table 4-2. Open VMS Operating System AXP™ Software Rollout Schedule 



November '92 

January - June ‘93 

July - December '93 

January - June '94 

Operating 

System 

Open VMS AXP O/S VI .0 
(Open VMS VAX 5.4-2) 

OpenVMS OVS, AXP, version 1.5 
SMP 

New Batch/Phnt 
Network Booting 

POSIX (1003.1, .2) 

Open VMS O/S AXP, 

Version "EPSILON" 
Volume Shadowing 
Host-Based 
RMS Journaling 
(Open VMS VAX 5.5) 

Cluster 


VMS cluster, 

(Initial configurations, limited 
multi-architecture, dual-host DSSI) 

VAXcluster Console 

VMS clusters 
(expanded configurations) 

Networks 

DECnet (end node) 

TCP/IP Services 

X.25 SNA 3270 

DECnet/OSI 
Mail Transport 
x.500 Server 

CDE 

MAILbus 400 

Language 

and 

Application 

Development 

DEC FORTRAN 
DEC C 

MACRO-64 assembler 
DXML (math library) 
DECset (full) 

Pascal Ada 

OPS5 VUIT 

DEC COBOL 

DECps Datatrieve 
C++ RALLY 

PL/I 

Middleware 

DECwindows Motif 
(Including CDA, Bookreader) 

NAS 250 & 300 
Advanced Developer Kit 

SQL Services ACAS DQS 

GKS PHIGS DEC AVS 

DECmessageQ Message Router 

POLYCENTER Agent Open 3D 

NAS 200, 250, 300 Integrated Runtime 

DEC/EDI 
DECamds (driver) 

NAS 400 Integrated Runtime 

Transaction 

Processing 

and 

Information 

Management 

FMS 

Rdb DBMS DSM 

ACMS Desktop Client 
SQL Multimedia, VI. 1 
CDD/Repository DECforms 

Data Distributor 
DECobject database 
ACCESSWORKS 
Instant SQL 
ACMS runtime 

Rdb/Expert 

ACMS Development 

RTR 

End User 
Tools 


OECwrite Notes 

DECpresent DECchart 



Other 

DECram DECmigrate 

PATHWORKS DECscheduler 

POLYCENTER SW DIS 

ALL-IN-1 Integrated Office 
System 

SERdb 


OpenVMS™ AXP™ Systems Software Public Schedule 

Source: Digital Equipment Corporation 01 Feb 1993 


Our evaluation also addressed upgrades of COTS packages in addition to their availability 
on Open VMS. For example, Oracle Corporation released its new version (Oracle 7.0. 1 3) on 
Alpha, but not the version (Oracle 6.0.33) ASAS was currently built against. This required the 
ASAS Project to upgrade to Oracle 7.0 and address the COTS upgrade issues, as well. The ASAS 
Project expended a considerable amount of time integrating and testing new versions of COTS 
products on the Alpha AXP. Several times during the migration of ASAS, receipt of a patch to a 
COTS package was critical to making continued progress. 


4.3.2 Migration Strategy for Software Items 

Once third-party packages were obtained and made operational, the previously developed 
VAX 3800 application code had to be evaluated. The migration of ASAS involved code written in 
many languages: C, FORTRAN, ADA, PASCAL, and MACRO-32. MACRO-32 code had to be 
completely rewritten, as this is a VAX processor-specific language. ASAS had less than 1000 lines 
of MACRO-32, and this was rewritten in C. 

Compiler availability for the Alpha AXP determined which software items could be 
compiled native on the Alpha AXP. Some items were vested since a compiler was not yet 
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available. It is possible, however, to combine both native and vested code in an Alpha AXP 
executable. We used native compiled code where possible, but linking vested and native software 
together worked well, also. 

In addition to identifying those software items that could be compiled, an evaluation of the 
source code was conducted to identify coding practices that would affect recompilation on the 
Alpha AXP. These practices did not keep applications from running on OpenVMS, but they did 
have a significant impact on performance. Two major differences between the VAX and Alpha 
AXP architecture are: (1) data alignment and (2) choice of data type. Data is naturally aligned 
when its address is an integral multiple of the size of data in bytes. For example, a long word is 
naturally aligned at any address that is a multiple of 4. A structure is naturally aligned when all its 
members are naturally aligned. On Alpha AXP systems, the default is to align each data item 
naturally, so the Alpha AXP does not provide hardware support to minimize the performance 
degradation from using unaligned data. Our experience has shown that references to naturally 
aligned data on OpenVMS Alpha AXP systems are 10 to 100 times faster than references to 
unaligned data. 

The Alpha AXP’s RISC architecture does not perform VAX D-floating arithmetic (56 bits 
of precision) and does not support the H-floating point data type. Because Alpha AXP compilers 
do not support H-floating data, modifications to use G-floating were made where possible. There 
were a number of other issues that were reviewed when compiling on the Alpha AXP. The VEST 
utility served as a tool to identify them, such as: 

• Static unaligned data. 

• Floating point references (H-floating and D-floating). 

• Privileged code. 

• Nonstandard coding practices. 

• Code referenced to openVMS data or code other than by using system services. 

• Uninitialized variables. 


With the results of the evaluation complete, a module-by-module plan was defined to 
identify the specific migration method for that module. Clearly, a simple recompile and link was 
the goal, but our migration schedule dictated that vesting was necessary, as well. The two 
migration paths are compared in Table 4-3. 

4.3.3 Maintain Existing Look and Feel 

The migration of the user interface was critical to the success of our effort. The goal was to 
provide an identical “look and feel” to the user. Essential to maintaining the look and feel was the 
migration of the menus and forms that are currently in use. The AS AS system has 1,143 forms for 
controlling various aspects of the user interface. If modification to the forms or to the code 
supporting the forms had been required, the magnitude of the migration effort would have increased 
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Table 4-3. Migration Path Comparison 


Factor 


Recompile/Relink 


(NATIVE) 


Translate 


(VESTED) 


Full Alpha AXP capability 


Performance 

Effort required 
Schedule constraints 

Programs Supported 
Age 

Limitations 
VAX Compatibility 

Ongoing support maintenance 


Varies; easy to difficult 

Based on availability of native 
compilers 


PreVAX VMS Version 4.0 source 
accepted 

Privileged Code supported 

High: most code will recompile 
and link without difficulty 

Normal source code and 
maintenance 


Typically 25 to 40% of native 
Alpha AXP potential 

Easy 

None: Available now 

Only OpenVMS VAX Version 4.0 
or later supported 

Only user mode code supported 

Complete via emulation 

No source maintenance 


significantly. It would also have meant that the forms and form handling would change for the 
user. The effort spent in providing an identical “look and feel” was well spent, as impacts to 
documentation and training would have significantly increased the overall cost and schedule for 
upgrading to the Alpha AXP. 

4.3.4 Test, Evaluation, and Tuning 

As the software was being migrated, other engineers were developing the test and validation 
environment. Test software was evaluated and migrated in the same fashion as the applications 
code was handled. Test data files were easily transferred to the Alpha AXP system through 
conversion utilities supplied by Digital. A complete set of regression and stress test procedures was 
developed to validate the accuracy of the migration. 

It was important to measure the improvements in performance gained by the Alpha AXP 
migration. Consequently, a complete set of performance measures were developed. The 
evaluation of performance was conducted in a number of different areas to assess overall system 
performance improvements. Those areas include: 

• System initialization and startup 

• Process activation from menus 

• Database access times for read and writes 

• Graphics operations 

• Computation-intensive functions or modeling 

• I/O-intensive operations 
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There were several findings about system performance. The more significant findings are 
covered here. The most striking performance statistic was that the system could operate at 
extremely high rates even with the reduction of four background processors previously required 
with the 3800 VAX systems. It was found that the six Alpha AXP processors included with the 
new Alpha AXP configuration provided more than enough computing power. In fact, system 
level performance improvements were found to be between 20 to 30 times for computing- 
intensive activities and up to 50 times for graphic functions. Supplementing the Alpha AXP with 
additional main memory provided a performance improvement in itself, because executables in 
this RISC architecture are much larger. Memory pages themselves are defined as 8192 versus 
512 bytes. Testing was conducted in 64 MB increments to determine the optimal memory 
configuration. A minimal system configuration of 192 MB of RAM was found to provide 
optimal configuration for each Alpha AXP computer. The number of disk drives in the system 
also affected performance as well. Database-intensive operations benefited from multiple drive 
configurations. The optimum configuration for each ASAS workstation was three and 1 .4 GB 
disk drives. In the case of the ASAS system, the number of processors was reduced, due to the 
significant increases in system performance. 


5.0 Conclusions 

Based on the experience of migrating ASAS, migration of existing applications from VAX 
to the Alpha AXP can provide many benefits; 

• Eliminate performance bottlenecks. 

• Reduce the system footprint. 

• Provide a hardware platform that runs three operating systems. Open VMS, OSF/1 , 
WindowsNT. 

• Increase programmer productivity. 

• Provide a platform for future enhancements. 

As described in the previous sections, a number of factors can add to the complexity of a 
migration. Typically, an application that has been well designed and followed standards for 
software development has a high probability of success. For example, the ASAS software using 
Open VMS 1.5, Oracle 7.0.13, Smartstar, Multinet, DECnet, and XGKS was completed in 10 
months. The software and hardware prototype was completed and operational testing started in 
December 1993. This was accomplished using a team of 14 software engineers and 2 hardware 
engineers. The operational testing of the Alpha AXP lasted approximately 2 months and concluded 
with a successful test of the Alpha AXP in the Warfighter exercise at Ft. Hood, Texas. 

At the beginning of the ASAS migration effort, the focus of the activity was on completing 
the migration. The reduced configuration (6 Alpha AXP processors versus 10 VAX 3800s) worked 
very well. Further evaluation of system performance led to additional downsized configurations. It 
was found that the system could perform very well with a minimal configuration of just two Alpha 
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AXP-powered workstations. Consequently, a new, two-node configuration (two Alpha AXP 500s) 
was introduced and is now in use in the field. These new configurations provided the program with 
capabilities that were unforeseen until the advent of the Alpha AXP. In addition to simply 
providing these new configurations, the system performance can now truly be called “real-time.” 
The processing and correlation of intelligence data are now processed by AS AS at the speed at 
which the communications system can deliver messages. The operational testing at Ft. Hood 
demonstrated that the analyst workload was sufficiently reduced for the first time. The speed of the 
system allowed analysts to perform their primary function, analysis of the battlefield situation. At 
the completion of the exercise at Ft. Hood, the consensus from the customer and the user was 
unanimous. The Alpha AXP was dramatically faster and the benefits from migration are well 
worth the cost. 
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